Discussion:Merise (informatique)

Demande d'explication

salut je fait une analyse d'un forum dans un site d'une ecole et j'ai trouvé une relation (1,0) --->(1,1) et je c'est pas comment je peut traiter cett cas SVP?

— Le message qui précède, non signé, a été déposé par un utilisateur sous l’IP 81.57.12.226 (discuter), le 8 avril 2005 à 22:57‎ UTC.

Bonjour, admirateur inconnu de la méthode MERISE (ou supposé tel), je réponds, bien que ce ne soit pas la place pour une telle question.

Il n'y a pas de flèches entre les cardinalités, mais un rond qui représente la relation, et deux pattes qui vont vers les cardinalités (en réalité vers les entités) ceci pour signifier que le niveau conceptuel ne préjuge pas des solutions apportées aux niveaux suivants (logique et physique) et donc pas encore de la transformation de la relation en future table dans un SGBDR, ni de l'existence de la table B en cas de dé-normalisation du modèle.

On a, en cas de choix d'un SGBDR, deux tables :

celle marquée (1,1) est la table A avec un identifiant ID-A, et ses colonnes de propriétés ;

celle marquée (0-1) est la table B qui contient ou non les propriétés de l'option si elle a été souscrite.

Il y a des solutions de dé-normalisation pour faire disparaitre la table B et tout mettre dans A, mais au prix de contraintes d'intégrité (traitement logiciel pour garantir ou vérifier la validité des données issue de B (doivent être toutes de valeur NULL ou toutes renseignées.

Michel Hevia (discuter) 9 octobre 2017 à 08:36 (CEST)

UML

Pour information, UML n'est pas une méthode mais un langage, donc dire que UML peut faire de la concurrence à Merise est faux. Certaines méthodes s'appuient sur UML (comme UP) et c'est à propos de celles-ci que l'on peut dire qu'elles concurrencent (d'ailleurs, qui fait encore du Merise aujourd'hui?) --Picrap 7 décembre 2006 à 11:03 (CET)

Pas faux, et c'est vrai que je connais moins UML que je ne connais MERISE. Je me souviens d'ailleurs de discussions byzantines du même genre sur méthode et méthodologie. Pour moi UML est plus qu'un langage, mais effectivement moins qu'une méthode. Le périmètre d'UML n'est pas le même que celui de MERISE, entièrement d'accord, mais en fait ce que je voulais surtout dire... c'est qu'il n'y a aujourd'hui pas grand chose d'autre qu'UML. Je tiendrais donc compte de votre remarque dans une prochaine mouture.

Je ne connais pas UP, mais je connais plein de vieilles méthodes comme SDM, HIPO, PS, Axial... que plus personne ne pratique plus, c'est vrai.

En particulier, pour moi, un des grands apports de Merise, systématiquement oublié par ceux qui en parlent en se focalisant sur le formalisme, c'est le cycle de projet. C'est surtout de cela dont il faudrait parler et qui reste encore un peu dans le vocabulaire : SD, EP, ED...

Dés que j'ai un peu de temps je vais essayer de remanier plus profondément l'article, qui me semble trés "copié/collé" d'une source pas trés bien documentée et un peu marginale.

N'hésitez pas à venir me corriger si je dérape

--AchilleT 8 décembre 2006 à 00:28 (CET)

Pour moi si, il y a encore du MERISE, mais, on fait du MERISE sans le savoir... comme M. Jourdain...

Michel Hevia (discuter) 9 octobre 2017 à 08:36 (CEST)

Acronyme

Une fois, j'ai entendu la signification de MERISE : Moyen Emmerdant Et Risqué d'Introduire Systématiquement de Ennuis :-) Christophe MOUSTIER 26 avr 2005 à 00:17 (CEST)

Moui, remarque qui fait bien avancer le Chimmmmimmilibilc...

Déplacement

Si par hasard des infos originales (provenant d'une page supprimée) nezumi ♦ discuter 29 jun 2005 à 08:43 (CEST) : Un modèle conceptuel de données (MCD) est une représentation simplifiée d’une réalité. Autrement dit un MCD n’est pas directement utilisable par une machine, mais c’est un mode de représentation intermédiaire entre la réalité observée et la machine avec son logiciel. Son objet est de mettre en lumière les caractéristiques essentielles du système d’information observé. Le modèle Entité/Relation est censé dégager des ensembles de données et les relations de sens qu’entretiennent ces ensembles. Une fois le modèle établi et validé par rapport a la réalité observée, il existe des règles permettant de le transformer en fichiers ou en base de données.

Ravi de cette mise au point : tout modèle ou théorie plus ou moins scientifique n'est qu'une abstraction de la réalité...

la mécanique classique, les théories de la relativité, la mécanique ondulatoire, les théories ondulatoire ou quantique de la lumière sont des abstractions du réel.

Elles ne sont pas LA réalité : je me marre quand un journaliste « scientifique » nous révèle qu'un jour (quand ?) ON pourra remonter le temps (c'est qui, c'est quoi, « ON » )...

Il en est de même avec les systèmes d'information et leurs modèles de plus en plus abstraits au fur et à mesure que l'on s'éloigne de l'objet réel étudié... :

c'est dans MERISE, c'est le cycle d'abstraction...

Niveau Conceptuel/organisationnel, puis logique, puis physique... et si le physique obtenu est irréaliste ou irréalisable à cause de ce que l'on va obtenir :m

taille de la mémoire (masse ou centrale),

puissance et temps de calcul ou de traitement,

coûts prévisionnels pour l'entreprise, en investissement ou en fonctionnement, résultats trop ambitieux pour une PME (certains cas particuliers rares peuvent-ils être résolus avec une suite bureautique... ? puis on entre cela dans la compta générale !)

... on retourne voir ce qui a péché au niveau logique, conceptuel, ou même au niveau de l'étude préalable... On a donc une itération du processus de conception.

Une abstraction est forcément une simplification de ce qu'est la réalité : on ne s'intéresse qu'aux caractéristiques utiles au but poursuivi :

si l'on cherche à gérer une entreprise, une personne n'aura pas pas pour propriété son génome... quoique si c'est une compagnie d'assurance vie ou maladie, il pourrait y avoir des tentations... (mais il y a la loi informatique et liberté à considérer pour les info nominatives) ;

par contre, les caractéristiques telles que la description des articulations héritées d'un modèle Etre-Humain, avec taille, poids, force, rapidité etc., qui sont caractéristiques de chaque individu, est utile pour faire courir une personne dans un jeu vidéo... pas pour gérer des comptes bancaires.

Exemple de problème sémantique qui aide au niveau conceptuel : c'est quoi un client... personne physique, personne morale ? Donc une personne ! Mais si assurance vie l'assuré est forcément une personne physique... le payeur peut être les deux, et le contractant (propriétaire du contrat), les deux également, mais pas en même temps : une personne est soit physique soit morale... Comme un BON système d'information ne doit pas avoir de redondances autres que celles nécessaires à l'établissement des relations (identifiants et clefs étrangères), une entité personne (abstraction juridique d'une personne; déclinée en physique OU BIEN morale) n'est qu'une seule fois dans le système d'information, et cette entité est reliée avec d'autres entités (contrat, garantie, compte...) grâce à des relations, comme EST_ACTEUR, porteuse de propriétés, par exemple RÔLE...

Maintenant c'est sûr : sémantique, abstraction (juridique, scientifique, littéraire...), c'est utilisable aussi bien pour concevoir un système d'information d'entreprise qu'un jeu vidéo...

Quant aux notions d'objet, de message, de client, de serveur, cela ne conduit qu'à définir de nouveaux types d'acteurs, d'entités, de propriétés, de flux...

Certains systèmes d'informations seront riches ou pauvres en types d'acteurs, de données, de flux, de traitements, de déclencheurs... parfois de certains seulement, ou de tout à la fois. Un point commun et inévitable : écrire les règles de gestion ; en tirer les différents concepts du point de vue des données ou des traitements. Encapsuler ensuite ou pas, c'est un autre problème. Car le client veut rester propriétaire de ses données, et le fabricant du logiciel de ses « programmes »... vous voyez l'embrouille juridique ? Pour un jeu vidéo, la propriété des données est autre : l'essentiel des données n'est pas mise dans le logiciel par le joueur, et leur richesse intellectuelle appartient à l'auteur, ou au fabriquant ; ce que fait le joueur avec ses clics est une info volatile... (sauf peut-être en phase de test)donc nuance ! Système embarqué : la log (l'historique de ce qui s'est passé est fort important... juridiquement parlant), et cela peut aussi l'être pour un système de gestion (traçabilité), ou en test.

Michel Hevia (discuter) 9 octobre 2017 à 16:38 (CEST)

blabla

j'ai déplacé ici (par correction) le texte d'un internaute qui avait pollué l'article. BMR 11 septembre 2006 à 10:12 (CEST)

slt moi je n'ai pas d'adresse ip mais je surf dans un cyber café, jui une malgache , j'habite à madagascar, jui mainant en 3em année d'étude, é pour le projet de fin d'étude je devrai informatisé une station service, mon problème est sur la réalisation, pour la méthode j'ai utilisé merise, pour le support access, si vous pouvez m'aider appelle moi sur 0331201355 ou en reste en contacte sur mon email bozykely23@yahoo.fr merci d'avance

Merise et gestion de projet

Merise n'est pas une méthode de gestion de projet; c'est une méthode de conception des Système d'Information.

Bien des projets SI ont capoté en France à cause du doute induit par certains écrits qui ont laissé croire que Merise était une démarche de gestion de projet. Les bases de la gestion de projets se trouvent dans des écrits comme ceux du PMI, IPMA ou Prince2 ...

Bernard Quinio (d) 22 novembre 2007 à 08:49 (CET) MCF en gestion / enseignant en système d'information et gestion de projet

Positionnement de la méthode

Je propose de modifier la 1ère phrase du paragraphe Positionnement de la méthode (La méthode Merise est une méthode d'analyse, de conception et de réalisation de systèmes d'informations informatisés) comme suit :

Merise est une méthode de conception et de développement de système d'information.

Source : Avant-propos de P. CONRUYT in "La méthode Merise, Tome 1 Principes et Outils, Les éditions d'organisation 1989"

En effet, Merise ne se limite pas au S.I. informatisé (SII), elle traite aussi du S.I. organisationnel (SIO). StonedDwarf (d) 17 octobre 2010 à 23:03 (CEST)

D'accord. Cantons-de-l'Est 18 octobre 2010 à 00:00 (CEST)

D'accord aussi, MERISE pourrait permettre de concevoir un système totalement fait de tâches humaines avec des fiches en carton dans des bacs... ou améliorer cette façon de FAIRE avec des cartes perforées et des trilleuses, OU la perfectionner avec des fichiers numériques et des tâches automatisées avec toutes les solutions possibles entre les deux extrêmes. MAIS dans tous les cas, il faut définir toutes les données nécessaires (avec des gens du métier, et des informaticiens cultivés, on peut se mettre d'accord sur la sémantique et ses implications...), les bons évènements déclencheurs et les traitements exhaustifs... c'est MERISE... Parce que une entreprise, avant MERISE et les « grands projets » que soit-disant il n'y a plus, il y avait donc dans une entreprise autant de fichiers clients que d'applications, que de domaines ou que de métiers au sens restreint : Assureur oui, mais vie, épargne, rente, automobile, incendie, vol, grêle etc. pour prendre le cas d'une compagnie d'assurance. Avec tous les sous-systèmes comptables que l'on peut imaginer...

Michel Hevia (discuter) 9 octobre 2017 à 08:36 (CEST)

Introduction

Vu l'audience de l'article (12000 consultations par mois), il est important de bien situer Merise dès l'introduction. En particulier, Merise a été très utilisée dans les années 1970 et 1980, mais a été moins mise en avant dans les années 1990 à partir du moment où les entreprises ont dû déployer, pour passer l'an 2000, des progiciels de gestion intégrée dans lesquels les modèles de données étaient tout faits. Depuis les années 2000, ce qui émerge, ce sont des préoccupations sociétales (développement durable), pour lesquelles Merise n'est pas la meilleure méthode. En particulier, la sémantique des données ne peut pas être modélisée par Merise.Pautard (d) 28 janvier 2011 à 11:39 (CET)

??? Bonjour. Je ne connais pas beaucoup de méthodes de conception de SI, qui soit en mesure d'avoir des ambitions "sociétales". Merise peut avoir des défauts, notamment celui de ne pas tout à fait avoir suivi les évolutions technologiques depuis la fin des années 1990 (SGBD, Objet, RAD, Client/serveur, Web, progiciels...), et d'être lourde à mettre en oeuvre , mais alors "sociétale" et "développement durable", je ne vois pas...

De même, votre affirmation "la sémantique des données ne peut pas être modélisée par Merise" est un peu définitive, et me semble t'il peu conforme à la Wikiétiquette. Un des principaux apports de Merise est au contraire de modéliser les données, et de fixer leur "sémantique" dans la limite toutefois de leur contribution au SI. C'est en tout cas tout à fait clair, dans la conception de ces auteurs, et en cherchant un peu je peux vous trouver tous les passages où ils formulent exactement cette notion. Cependant, il ne s'agit pas bien sur de sémantique pure, mais seulement d'informatique. le terme est sans doute trop fort, et utilisé mal à propos par les auteurs même de Merise. Merise reste un outil puissant pour exprimer une vision partagée, et modéliser une même définition (le mot me semble moins verbeux et plus précis que "sémantique") des données de l'entreprise. Merise n'a rien d'un outil de sémantique, utilisable par des sémiologues. Que penseriez-vous d'un adoucissement de votre contribution allant dans ce sens ? Cordialement--AchilleT (d) 13 février 2011 à 12:47 (CET)

Je pense au contraire qu'il faudrait conserver le terme "sémantique" en ce qui concerne la modélisation des données. Bien que ce terme, comme AchilleT le fait remarquer à juste titre, n'est pas à prendre dans son acception première (i.e. au sens "utilisable par des sémiologues"), il est "consacré" par des décennies de pratique. Il suffirait simplement d'avertir le lecteur par une note (accrochée au terme "sémantique") expliquant cela.

Concernant l'intervention de Pautard, l'affirmation selon laquelle les entreprises ont dû déployer, pour passer l'an 2000, des progiciels de gestion intégrée ne reflète qu'une partie de la réalité, l'autre partie étant que les entreprises ont dû déployer des armées d'informaticiens, transformés pour l'occasion en géologues, parfois même en archéologues, pour les aider à corriger leurs systèmes informatiques afin qu'il passent l'an 2000. Par ailleurs, je ne vois pas bien le lien entre la mise en place des PGI dans les années 2000 et les préoccupations sociétales conduisant à l'inaptitude de Merise...--StonedDwarf (d) 14 mars 2011 à 01:19 (CET)

Je ne vois pas ce que le bug de l'an 2000 parce qu'on stockais l'année sur 2 chiffres au lieux de 4 à a voir avec la méthode merise. MERISE est juste IDÉALE pour gérer les données dans une base (MCD, MLD, MPD). Par contre elle n'est pas optimale dans la gestion des traitements modernes Objets événementiels et multiprogramés. Pour cette partie UML est juste IDÉAL. Enfin la gestion de projet n'a ni à voir avec MERISE, ni avec UML. C'est un paris que prend le chef de projet sur le coût et le délais de développement d'une application et il à ses propres règles d'estimations mais cela reste une ESTIMATION et n'a rien à voir avec des outils de développement qui eux sont fiables pour le développement logiciel sans contraintes de temps ni d'argent. — Le message qui précède, non signé, a été déposé par 78.193.104.152 (discuter)

Niveau organisationnel / Niveau logique

L'article laisse penser que le niveau logique ou organisationnel sont similaires dans la méthode merise, c'est complètement faux! Les modèles organisationnelles traitent la question du qui, tandis que le modèle logique traite la question du comment, il s'agit là d'approches bien différentes... Est-il possible de mettre un warning sur la page en attendant une correction?

L'article laisse à penser que logique et organisationnel sont au même niveau parce que c'est vrai : niveau Logique pour les données (Modèle Logique de Données - MLD), niveau Organisationnel pour les Traitements (Modèle Organisationnel de Traitements - MOT). Ces niveaux traitent du "Qui", "Où" et "Quand". Le "Comment" relève des niveaux Physique pour les données (Modèle Physique de Données - MPD) et Opérationnel pour les traitements (Modèle Opérationnel de Traitements - MOPT). StonedDwarf (discuter) 12 octobre 2014 à 12:59 (CEST)

Absolument pas? Cours sur MERISE, Lien développez.com, pourtant présent dans les liens de l'article Il existe MLD, MLT, MOD, MOT. Les niveaux organisationnels seraiet à rapprocher du conceptuel au sens ou il s'agit de spécifications (qui est propriétaire de quelles données et quels traitements), tandis que les niveaux logiques rentrent dans la définition du système, les choix d'implémentation. Bref, rien à voir DU TOUT. JustinFernal (discuter) 27 février 2015 à 11:49 (CET)

A propos des CIF et des CIM

Bonjour, Je n'ai pas l'habitude d'intervenir sur la page discussion, n'hésitez pas à modifier mon propos si vous ne le trouvez pas au bon endroit. La notion de CIF semble caractériser dans la description donnée dans cette page, une simple association aux cardinalités quelconques et non porteuse ("Les CIF ont pour particularité d'être binaires et d'avoir une cardinalité min à 0 ou 1 et une cardinalité max à 1 ou n, de plus elles ne sont pas porteuses de propriétés."). Pourquoi les appeler autrement ? Quelle est la source de cette définition ?

La notion de CIM est aussi finalement très flou et semble parler d'association non forcément binaire (donc ternaire aussi mais parfois binaire) et parfois porteuse ("Les CIM sont n-aires et ont toutes leurs cardinalités max à n, de plus elles peuvent être porteuses de propriétés."). Là aussi quelle est la source de cette définition peu précise ? A quoi peut bien servir une définition qui ne définit pas grand chose ?

Enfin, je ne comprends pas la présence de la dernière phrase qui n'est plus là pour décrire le MCD mais parler de programmation MVC : "Les associations ne sont plus utilisés aujourd'hui avec l'avènement de la programmation MVC. Le Modèle n'est pas censé contrôler les données, travail dévolu au contrôleur." Car pour moi, les associations sont toujours utilisées pour modéliser une base de données quel que soit la représentation utilisée (MCD ou UML).